Fail the site deployment when the site does not take it - #64
Merged
Conversation
A GitHub Pages deployment can report success, be recorded as the active deployment, and still leave the site serving the previous one. That is what happened to 1.0.0: the release-triggered run waited for the release to appear, wrote the correct manifests, uploaded them, and deployed them, all green, and the download page went on offering 0.9.5 for as long as nobody looked. Re-running the workflow published the same bytes and they were live on the first request. Reading the site back is the only place that failure shows, so the workflow now does it and fails if the manifests it just deployed are not the ones being served. It compares against the deployed files rather than against the newest release, because a pre-release deployment leaves stable.json untouched and a check written the other way would fail on every one of them. The window before it gives up is generous: slow propagation and a stuck deployment look identical at first, and only one is worth interrupting a release for. The check cannot repair anything, and is not meant to. The remedy stays Run workflow, which republishes the same files. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For 1.0.0 the release-triggered site deployment was green from end to end — it waited for
the release to appear in the API, wrote
stable.jsonas 1.0.0, uploaded the artifact, anddeployed it; GitHub recorded the deployment as successful and marked the previous one
inactive — and whiteboard.sqlbi.com kept serving the deployment from twenty minutes
earlier. The download page offered 0.9.5 with every check green. Re-running the workflow
published identical bytes and they were live on the first request.
I confirmed the artifact rather than inferring it: the one that run deployed contains
"version": "1.0.0". Nothing on our side was wrong, and nothing upstream of the site canreport that it did not take.
So the workflow now reads the manifests back from the live domain after deploying, and
fails if they are not the ones it just wrote.
Two design points worth stating, because both are easy to get backwards:
release. A pre-release deployment leaves
stable.jsonuntouched, which is correct, anda check written against the newest release would fail on every pre-release.
propagation and a stuck deployment are indistinguishable at first, and only one of them
justifies a red run during a release. Today's re-run was live with
Age: 0on the firstfetch, so there is a lot of headroom.
The check is read-only and cannot repair a deployment. That is intentional: the remedy is
Run workflow, which republishes the same files, and that has been enough every time.
scripts/verify-published-site.ps1also runs by hand against any folder holding aCNAMEand the manifests, which is how I tested it — matching manifests pass, a manifest ahead of
the site fails with the remedy named, no manifests skips cleanly, and a missing CNAME
gives a clear error.
What this does not cover is a run that never starts. If the
github-pagesenvironmentloses its
v*tag rule, the release-triggered run is rejected in seconds and no step ofours executes. That failure is at least visible in Actions as a rejected run. Catching it
would need a scheduled watchdog, which we decided against for now.
🤖 Generated with Claude Code